A Middleweight Requirements Management Framework

Software developers need to manage requirements. To do so, they can choose between “ultra-lightweight,” “lightweight,” and “heavyweight” requirements management tools. Ultra-lightweight tools are simple, flexible, and cheap but do not scale very well. Lightweight tools are also simple, flexible, and cheap but do not scale well. Heavyweight tools scale well, but are complex, inflexible, and costly. Problems with these tools are decreasing the quality and/or increasing the cost of non-trivial software development efforts. This paper presents a requirements management framework that is simple, flexible, and cheap in addition to scaling well: a middleweight requirements management tool. Introduction Organizations need to manage requirements for non-trivial systems they develop. It is an essential activity of both the system development lifecycle and the software development lifecycle [8]. But what are requirements and what does it mean to manage them? A requirement is a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents [1]. A requirement is categorized as “functional” if it specifies what the system needs to do. Otherwise, it is categorized as “nonfunctional.” A requirement can be embodied by a group of individual statements. For example: the requirement that a system be highly reliable can be embodied as: “The system shall be 99.997% reliable.” This embodiment, or artifact, can also have attributes associated with it. Common attributes are a name, a priority, and an estimated effort. Additionally, the embodiment can be associated with other artifacts. Common associations link a requirement to the implementation artifacts that support it or to the artifacts that describe how to test those implementation artifacts in order to meet the requirement. Although the distinction between a requirement and its embodiment is important in some contexts, it is not important here. For the duration of the paper, the term requirement refers to both the requirement and its embodiment. Managing requirements means at least two activities: managing the requirements artifacts themselves (elicitation and analysis) and using information from the requirements artifacts as an input into the project management process (scoping and prioritizing). Software developers manage requirement artifacts by: (1) adding a requirement to a requirement set; (2) changing a requirement in a requirement set; and (3) deleting a requirement from a requirement set. Changing a requirement may involve adding/changing/deleting attributes of a requirement or forming/breaking an association between a requirement and another artifact. Software developers use information from requirement artifacts in a variety of ways, ways that vary from simple to sophisticated. Consider a simple case. Assume that all current requirements for a release have been elicited and analyzed with respect to effort and priority. Further assume that the software developer playing the project manager role has been given an end date for the release. He or she will use the information associated with the requirements to help define the requirement set that is most desirable (priority) and achievable (effort) in the time allotted. Alternatively, they can negotiate for more time based on this information.